1) Fixed the silly "68000 stomping" bug that was introduced in 1.02a. I am now trying to rewrite history by claiming that the bug was actually a clever marketing ploy to create an upscale image by refusing to run on any "low class" machines.
2) Another change in FastTab 1.03 applies to those of who were accelerating mouse text selections, using the techniques described in the FastTab Tip Sheet #1. The technique does not work on multiple screen configurations if the stack window is not on the main screen. The selection does not appear inverted on the screen, even though the selection is made. Because FastTab was never designed to handle mouse clicks, I am stubbornly proclaiming that this is not a FastTab bug. At most it is a bug in the tip sheet which suggested a technique that did not work in all situations. This "invisible selection" problem used to occur for the "tabkey" and "select" cases in FastTab 1.00.
(Yes, I admit that for tabkey and select, it should be considered a bug.) Because acclerating mouse clicks may be useful, FastTab 1.03, as a *FEATURE*ENHANCEMENT*, has been changed to monitor mouse clicks and provide a fix for the multiple screen situation. Because this is almost a "copy and paste" of the code that fixed the problem for "tabkey" and "select", I am fairly confident that the new feature will not have a negative effect on FastTab's stability.
3) Actually, to properly handle all mouse clicking possibilities on multiple monitor systems, it has become necessary for FastTab to determine whether certain events are being invoked directly from HyperCard or from system software. As the Mac environment faces change, with things like protected memory on the horizon, this checking on return addresses may present some compatibility risk. (Or not. It's all just idle speculation.) If this test becomes invalid, it should not cause any crashing. Rather tabbing acceleration effectively will be turned off.
Stack distribution licensees who are concerned about this compatibility risk ╤ and who are not affected by the clicking problem ╤ may wish to discuss with Symplex a version with this additional checking removed.
4) Fixed an obscure bug that caused FastTab to crash when multiple copies were called recursively. The conditions to cause this bug require that FastTab be called recursively called at least three times, with the first and last invocation being called from a copy of FastTab in one stack while the middle invocation is called from another copy of FastTab in another stack or in the HyperCard application resource fork. This combination causes FastTab to crash. This bug emerged from internal analysis and testing. I do not believe it has occurred in any user installation.
Note: recursively calling FastTab from an exitField or closeField handler is legal, and I believe has always worked properly. The bug only occurs when another copy of FastTab is also invoked.
Existing single-CPU licenses and stack distribution licenses, are extended to this new version of FastTab.
